Issue #1333. Authoring is moving into `sbpp/sourcebans-pp` under
`docs/` (Astro Starlight); this repo is now a deploy shell only. The
README points contributors at the new source repo and includes a short
local-preview pointer for anyone who lands here looking for the docs.

Issue #1333. The Hugo + kube-theme stack served this repo from 2018
through the 1.7.x docs. With authoring moving into
`sbpp/sourcebans-pp/docs/` (Astro Starlight), nothing in this repo
needs to be built locally anymore — the deploy workflow pulls source
from the new location at deploy time.

Removed:
- Gruntfile.js, package.json, yarn.lock — the Lunr search index
  build that ran before Hugo on every deploy.
- archetypes/ — Hugo new-page templates (blog, docs, default).
- config.toml — Hugo site config (title, theme, menus, GA tag).
- content/ — 13 Hugo Markdown pages under docs/ + the FAQ index.
  Same content is being ported to Starlight in the sibling
  sourcebans-pp PR.
- layouts/ — Hugo layout overrides (404, baseof, list, single,
  index, partials/{favicon,footer,header}).
- static/ — vendored FontAwesome bundles, brand favicons, Lato
  font subset, and the master.css. The Starlight site uses its own
  font stack and ships its own favicon/brand mark.
- themes/kube — the upstream Hugo theme submodule
  (https://github.com/jeblister/kube), unmaintained since 2018.
- .gitmodules — only entry was themes/kube.
- .gitattributes — only rule was a Hugo-specific
  `static/updater/* linguist-detectable=false`, which the static/updater
  directory was already deleted by #51.

Kept:
- LICENSE — repo licence stays.
- .gitignore — generic OS/IDE ignores still useful.
- README.md — replaced in the previous commit with the deploy-shell
  pointer.
- .github/workflows/deploy.yml — replaced in the first commit with
  the new Pages deploy.

After this commit the working tree is exactly: LICENSE, README.md,
.gitignore, .github/workflows/deploy.yml. That's the deploy shell.

… m4, m5, m6)

Five small drift fixes against the sibling docs-build.yml in
sourcebans-pp so the validation gate and the deploy run in lockstep:

- M1 Node 22 -> 20. Sibling docs-build.yml uses 20 and the docs README
  documents "Node 20 LTS or newer" as the floor; deploying on a Node
  major the validation gate never tested could ship a build that
  passes CI and still fails here.

- M2 concurrency group `pages` -> `pages-deploy`. Issue #1333 §6
  specifies the latter; either choice serializes the same set of runs
  since this is the only Pages workflow in this repo, but tracking
  the spec verbatim makes the cross-repo intent obvious to anyone
  diffing the cutover. YAML comment added explaining the choice.

- m4 add `timeout-minutes: 15` on the build-and-deploy job. The
  sibling docs-screenshots.yml uses 30 (it boots docker compose +
  Playwright); deploy is build-only so 15 is comfortably above the
  steady-state runtime while still bounding an upstream hang.

- m5 `runs-on: ubuntu-latest` -> `ubuntu-24.04`. Matches the sibling
  workflows so the build runs on byte-identical runner images.
  ubuntu-latest currently floats to 24.04 anyway, but pinning means
  GitHub's eventual default-bump can't silently change what we deploy.

- m6 lift the per-step `working-directory: docs` to job-level
  `defaults.run.working-directory: docs`. Same shape the sibling
  docs-build.yml uses. Inputs to `uses:` actions
  (`cache-dependency-path: docs/package-lock.json`,
  `path: docs/dist`) stay rooted at the workspace because action
  inputs are interpreted relative to the workspace root, not the
  job's `working-directory` default — comment added to that effect
  so the asymmetry doesn't read as a bug.

No functional change to triggers, permissions, or the action
versions themselves; those are addressed in follow-up commits.

Two of the four pins were trailing current majors in ways that
matter; bumping the other two for symmetric upgrades.

- actions/upload-pages-artifact@v3 -> @v5. v3 was rolled forward to
  v4 in mid-2024 and to v5 in April 2026; the v5 line bundles
  upload-artifact@v7 (Node 24 runtime) ahead of GitHub's deprecation
  of Node 20 on the runner side. Staying on v3 silently relies on
  the deprecated upload-artifact@v4 chain and would break on the
  runner-side cutover.

- actions/deploy-pages@v4 -> @v5. v5 (March 2026) is the Node 24
  runtime version; same upcoming-deprecation calculus.

- actions/checkout@v4 -> @v5 and actions/setup-node@v4 -> @v5 for
  symmetric upgrades. v6 lines exist for both (checkout@v6.0.2,
  setup-node@v6.4.0) but v6 brings credential / runtime version
  bumps that the rest of the org's workflows haven't adopted yet —
  v5 is the conservative pick that still moves us off Node-20-era
  pins. The sibling sourcebans-pp workflows can follow on the same
  cadence.

No semantic change to inputs (cache-dependency-path, path, etc.) —
the v5 lines are drop-in for the inputs we use.

Sibling sourcebans-pp/.github/workflows/docs-deploy-trigger.yml
already sends the source commit SHA in the repository_dispatch
client_payload (`client_payload[source_sha]=${{ github.sha }}`); the
deploy was ignoring it and always checking out the floating
`sourcebans-pp@main` ref.

Race shape that was open: two pushes A, B land on sourcebans-pp main
in quick succession. The dispatcher fires twice (its own
`docs-deploy-trigger` concurrency group serializes the dispatch step
itself, but each dispatch produces its own run here). Run A starts
the checkout step after run B has already pushed, sees `main` now
points at B, and silently rebuilds from B — meaning the build labelled
"deploying SHA A" actually deploys SHA B.

Fix: `ref: ${{ github.event.client_payload.source_sha || 'main' }}`.
- repository_dispatch path -> pins to the source SHA the dispatcher
  captured at trigger time, so each run deploys exactly what the
  dispatcher meant.
- workflow_dispatch path -> empty payload, falls through to `main`
  (manual reruns explicitly want the latest tip).
- schedule path -> same: weekly safety-net wants the latest tip.

The fall-through default is the existing semantics, so non-dispatch
triggers behave exactly as before.

The Hugo source, package.json, yarn.lock, and themes/kube were all
removed in 55ff386 — leaving the matching ignore entries (`public`,
`dev`, `node_modules`) as dead lines that document a build pipeline
this repo no longer has. Anyone landing here looking for "where do
the build artifacts go?" would read those entries and get the wrong
mental model.

The remaining entries (Windows / OSX / NetBeans / Recycle Bin) are
generic OS/IDE artefacts that still apply to anyone editing
README.md or the deploy workflow locally; they stay.